-
Notifications
You must be signed in to change notification settings - Fork 561
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
i#7050 remove preempted instruction and memref. #7058
base: master
Are you sure you want to change the base?
Conversation
…ansfer. When an instruction is preempted by a kernel transfer, the instruction is not retired. The trace might not have captured all the read and write records. To avoid false positive, the invariant checker should reset the expected read and write record counters. Fixes #7050
…b.com:DynamoRIO/dynamorio into i7050-remove-preempted-instructions
@@ -13,7 +13,7 @@ Total counts: | |||
.* total data loads |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked back at the details and I really do not understand what is happening with this. Could you explain how this scenario occurred? I wrote some of my confusion at #7050 (comment).
Putting aside the fact that a regular asynch signal should not cause this kind of thing: if there were some real preempt from say thread relocation, why isn't raw2trace filling in the rest of the instructions in the block? How is the handler code running already? That makes it sound like raw2trace is already truncating the rest of the block and somehow solving #5790? On that note is this PR as written solving #5790?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is in the raw trace records? What is the instruction count for the shl
block? What is the exact raw trace order of the branch's block PC, shl block PC, shl address, and signal marker?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's the trace without the change:
1436 982: 94080 ifetch 4 byte(s) @ 0x0000aaaae1534568 54000061 b.ne $0x0000aaaae1534574 (untaken)
1437 983: 94080 ifetch 4 byte(s) @ 0x0000aaaae153456c 97ffffbd bl $0x0000aaaae1534460 -> %x30
1438 984: 94080 ifetch 4 byte(s) @ 0x0000aaaae1534460 a9be7bfd stp %x29 %x30 %sp $0xffffffffffffffe0 -> -0x20(%sp)[16byte] %sp
1439 984: 94080 write 16 byte(s) @ 0x0000fffffb68e260 by PC 0x0000aaaae1534460
1440 985: 94080 ifetch 4 byte(s) @ 0x0000aaaae1534464 910003fd add %sp $0x0000 lsl $0x00 -> %x29
1441 986: 94080 ifetch 4 byte(s) @ 0x0000aaaae1534468 90001bc0 adrp <rel> 0x0000aaaae18ac000 -> %x0
1442 987: 94080 ifetch 4 byte(s) @ 0x0000aaaae153446c f944dc00 ldr +0x09b8(%x0)[8byte] -> %x0
1443 987: 94080 read 8 byte(s) @ 0x0000aaaae18ac9b8 by PC 0x0000aaaae153446c
1444 988: 94080 ifetch 4 byte(s) @ 0x0000aaaae1534470 f9400001 ldr (%x0)[8byte] -> %x1
1445 988: 94080 read 8 byte(s) @ 0x0000fffeddbabb58 by PC 0x0000aaaae1534470
1446 989: 94080 ifetch 4 byte(s) @ 0x0000aaaae1534474 f9000fe1 str %x1 -> +0x18(%sp)[8byte]
1447 989: 94080 write 8 byte(s) @ 0x0000fffffb68e278 by PC 0x0000aaaae1534474
1448 990: 94080 ifetch 4 byte(s) @ 0x0000aaaae1534478 d2800001 movz $0x0000 lsl $0x00 -> %x1
1449 991: 94080 ifetch 4 byte(s) @ 0x0000aaaae153447c b90017ff str %wzr -> +0x14(%sp)[4byte]
1450 991: 94080 write 4 byte(s) @ 0x0000fffffb68e274 by PC 0x0000aaaae153447c
1451 992: 94080 ifetch 4 byte(s) @ 0x0000aaaae1534480 910053e0 add %sp $0x0014 lsl $0x00 -> %x0
1452 993: 94080 ifetch 4 byte(s) @ 0x0000aaaae1534484 d5087620 dc_ivac (%x0)[1byte]
1453 993: 94080 dflush 64 byte(s) @ 0x0000fffffb68e274 by PC 0x0000aaaad5087620
1454 993: 94080 <marker: kernel xfer from 0xaaaae1534484 to handler>
1455 993: 94080 <marker: signal #4>
1456 993: 94080 <marker: timestamp 13374886167543675>
1457 993: 94080 <marker: tid 94080 on core 53>
1458 994: 94080 ifetch 4 byte(s) @ 0x0000aaaae1534384 a9be7bfd stp %x29 %x30 %sp $0xffffffffffffffe0 -> -0x20(%sp)[16byte] %sp
1459 994: 94080 write 16 byte(s) @ 0x0000fffffb68cff0 by PC 0x0000aaaae1534384
Raw trace:
0010c0 0000fffffb68e29c 0000fffffb68e29c
0010d0 200200000006456c 2024000000064460 1437 983: 94080 ifetch 4 byte(s) @ 0x0000aaaae153456c 97ffffbd bl $0x0000aaaae1534460 -> %x30
1438 984: 94080 ifetch 4 byte(s) @ 0x0000aaaae1534460 a9be7bfd stp %x29 %x30 %sp $0xffffffffffffffe0 -> -0x20(%sp)[16byte] %sp
0010e0 0000fffffb68e260 0000aaaae18ac000
0010f0 0000fffeddbabb58 0000fffffb68e278
001100 0000fffffb68e274 0000fffffb68e274 1450 991: 94080 write 4 byte(s) @ 0x0000fffffb68e274 by PC 0x0000aaaae153447c
1450 991: 94080 write 4 byte(s) @ 0x0000fffffb68e274 by PC 0x0000aaaae153447c
001110 c200aaaae1534484 c228000000000004 1454 993: 94080 <marker: kernel xfer from 0xaaaae1534484 to handler>
1455 993: 94080 <marker: signal #4>
001120 802f84635aed7f7b c203000000000035
001130 2022000000064384 0000fffffb68cff0
001140 0000fffffb68d00c 0000aaaae18bde60
001150 0000aaaae18bde60 0000aaaae18bde60
Change the implementation to remove instructions and memrefs preempted by kernel events.
Interruption by RSEQ ABORT follows by KERNEL EVENT is already handled by handle_kernel_interrupt_and_markers().
Unit test test_rseq_rollback_legacy covers this case.
In oder to remove preempted instructions and memrefs, a new function preempted_by_kernel_event() is added to look for KERNEL EVENT marker which may be preceded by memrefs. If a KERNEL EVENT marker is found with the same PC, the instruction and any following memrefs are removed.
Add unit tests to cover instruction and memref removed caused by a KERNEL EVENT.
Update offline-legacy-int-offs.templatex, offline-burst_aarch64_sys.templatex and signal_invariants.c to account for removed instructions.
Fixes #7050